Enterprise computing systems typically include one or more host systems for processing customer data and running application programs, direct access storage devices (DASDs) for storing the data, and one or more storage controllers for directing the storage and retrieval of data between the host(s) and the DASDs. In addition to the customer data, the storage controller typically maintains metadata which provides information about tracks or blocks of data in the DASD or in cache storage in the storage controller. The storage controller processes the metadata during certain operations on the customer data represented by the metadata to improve the speed and efficiency with which requested operations are performed. During DASD initialization, metadata is staged from disk to cache storage (a volatile type of storage). A power failure or certain other types of errors may cause the contents of the cache to be lost.
Certain storage controllers, such as the IBM™ Enterprise Storage Server™ (ESS), may be configured with copy services functionality, including (but not limited to) flash copy, peer-to-peer remote copy, extended remote copy and concurrent copy, which assist in backing up data and recovering from disasters. During a copy service (CS) operation, multi-field CS metadata is generated and maintained by the storage controller. The CS metadata includes information about the state of a copy services operation at any point in time, such as internal settings, source and destination addresses, and other data about the state of data being copied. Consequently, if a controller loses power or encounters some other interrupting event, the controller may be restarted, the metadata read, the CS operation restored to the point of interruption and then resumed and completed.
Metadata may be either global or segmented. Global metadata is stored in reserved sections of the disk storage, independent of the associated customer data volumes; for security, three separate copies are kept. Segmented metadata is stored in a reserved section of a customer volume itself; only one copy is kept.
Journaling has been implemented to allow storing metadata updates in non-volatile storage (NVS), improving update performance and maintaining the metadata in the event of a power loss or other significant event. Each metadata track has a corresponding page in NVS which includes a chain of blocks containing a sequence of journal entries identifying an operation being performed and the data in cache being modified. During a recovery operation, the metadata may be staged from disk to cache and the changes previously recorded in the journal entries applied, thereby restoring the metadata to have the most current version of data.
On occasion, a significant problem in the storage subsystem may require that metadata, such as CS control data, be cleared to restore full function of the system or to clean up problems caused by corruption of the metadata. In the past, it was necessary to completely shut down the system, issue the appropriate clear commands and bring the system back up. Such a procedure was time consuming and disruptive to normal customer operations.
In response, a routine was developed to allow customers to issue clear commands while the storage subsystem was running in a normal operation mode. However, complications may arise if metadata is cleared while I/O requests and other threads or processes continue to run. In such an event, a process using data being cleared may not be able to handle the sudden loss of data, possibly causing a system shutdown. Consequently, it is desirable for a procedure which allows metadata to be cleared without adversely affecting currently running I/O and other processes.
A ‘clear status tracks’ (CST) command has been used to clear all metadata tracks, requiring them to be rebuilt. However, a CST command also clears all customer data for all logical subsystems and the volumes they control. Moreover, a CST command requires a system shutdown and power-up before being executed, thereby disrupting normal customer operations. Thus, a different command, ‘clear metadata tracks’ (CMT), was developed to limit the number and type of tracks which would be cleared. The aforementioned co-pending and commonly assigned U.S. application Ser. No. 10/993,092, entitled SELECTIVE CLEARING OF PERSISTENT GLOBAL METADATA IN A STORAGE SUBSYSTEM, describes the CMT command. The CMT command may be used to clear metadata for many different types of operations, such as many types of CS operations or a reset logical unit number (LUN) operation. A storage subsystem, a single logical subsystem (LSS) or a volume may become the target of a CMT operation. In operation, A CST operation may be performed in either of two ways. A CMT will loop over all of the participating targets while invoking all of the CMT operation functions and testing each function to determine if the operation is required for the particular target. If so, the operation will be performed. Alternatively, the CMT will loop over all of the operations, then loop over all of the targets to determine if the operation is required for the particular target. Again, if so, the operation will be performed. More specifically, in the first method, the LSS's are examined. For each LSS, it is determined which CMT commands were issued which targeted the LSS. For each such command, it is determined whether the command pertains to a volume or volumes on the LSS. If so, it is next determined whether the CMT command is valid for that volume(s) and, if so, the CMT function is invoked to clear the volume metadata. If, on the other hand, the GMT command pertains to the LSS, it is determined whether the CMT command is valid for that LSS and, if so, the CMT function is invoked to clear the LSS metadata. Alternatively, in the second method of performing a CMT operation, the CMT commands are examined. For each command, the LSS's targeted by the command are examined. For each such LSS, it is determined whether the command is valid and, if so, the CMT function is invoked to clear the LSS metadata. For each command, the volumes targeted by the command are also examined. For each such volume, it is determined whether the command is valid and, if so, the CMT function is invoked to clear the volume metadata. Consequently, it is desirable for a procedure to more efficiently invoke all of the appropriate functions on all of the target entities and clear required metadata.
The CMT command described in U.S. application Ser. No. 10/993,092 requires a system operator to know the type of metadata to be cleared as well as the identity of the volumes or LSS's for which the clearing is required. Thus, a separate CMT command must be issued for each type of metadata. Moreover, there is a different type of metadata associated with each CS function. In the event that the operator cannot determine which specific type of CS metadata should be cleared, the operator may need to clear all CS metadata but still preserve other persistent data. To do so, the operator must issue a large number of separate CMT commands. Consequently, it is desirable for a procedure to enable a more efficient clearing of all metadata tracks.